我通常在 Stack 上发布与代码相关的内容，但这更多是关于社区的一般想法的问题。
似乎有很多人提倡使用 Redux 和 React 来管理数据/状态，但是在阅读和学习两者时，我遇到了一些看起来不太正确的东西。
在此页面的底部：http ://redux.js.org/docs/basics/UsageWithReact.html （传递商店）它建议使用 React ‘Context’ 的“魔术”。
一种选择是将其作为道具传递给每个容器组件。然而，它变得乏味，因为您甚至必须通过展示组件来连接存储，因为它们恰好在组件树的深处渲染了一个容器。 我们推荐的选项是使用一个特殊的 React Redux 组件调用来神奇地使存储可用于所有容器组件......
一种选择是将其作为道具传递给每个容器组件。然而，它变得乏味，因为您甚至必须通过展示组件来连接存储，因为它们恰好在组件树的深处渲染了一个容器。
我们推荐的选项是使用一个特殊的 React Redux 组件调用来神奇地使存储可用于所有容器组件......
在 React Context 页面 顶部有一个警告：
上下文是一个高级和实验性的功能。API 可能会在未来的版本中发生变化。
然后在底部：
正如在编写清晰的代码时最好避免使用全局变量一样，在大多数情况下您应该避免使用上下文...... 不要使用上下文通过组件传递模型数据。通过树显式地线程化您的数据更容易理解......
正如在编写清晰的代码时最好避免使用全局变量一样，在大多数情况下您应该避免使用上下文......
不要使用上下文通过组件传递模型数据。通过树显式地线程化您的数据更容易理解......
Redux 建议使用 React ‘Context’ 特性，而不是store通过 ‘props’ 向下传递给每个组件。而 React 建议相反。
store
此外，似乎 Dan Abramov（Redux 的创建者）现在为 Facebook（React 的创建者）工作，只是为了让我更加困惑。
上下文是一项高级功能，可能会发生变化。在某些情况下，它的便利性超过了它的缺点，因此像 React Redux 和 React Router 这样的一些库选择依赖它，尽管它具有实验性质。
这里的重要部分是单词库。如果上下文改变了它的行为，我们作为库作者将需要调整. 但是，只要库不要求您直接使用上下文 API，您作为用户就不必担心对其进行更改。
React Redux 在内部使用上下文，但它没有在公共 API 中公开这一事实。所以你应该觉得通过 React Redux 使用上下文比直接使用上下文更安全，因为如果它发生变化，更新代码的负担将落在 React Redux 而不是你身上。
最终 React Redux 仍然支持始终将 store 作为 prop 传递，所以如果你想完全避免上下文，你可以选择。但是我会说这是不切实际的。
TLDR：除非您真的知道自己在做什么，否则请避免直接使用上下文。使用恰好在内部依赖上下文的库是相对安全的。
